In a distributed network, there are typically a plurality of network devices and one or more devices that collect information on those devices for network management purposes. Current technology typically uses the Simple Network Management Protocol (SNMP) for tracking changes to the various network resources associated with the network devices. The SNMP architecture is described in detail in Internet Engineering Task Force Request for Comment 2571 entitled “An Architecture for Describing SNMP Management Frameworks,” April 1999 (hereinafter referred to as RFC 2571), which is incorporated herein by reference.
Referring to FIG. 1, the SNMP messages are generally exchanged between a central network management system (CNMS) 102 and a plurality of network devices or agents, including managed network devices (MND) 104-105. The CNMS 102 acquires information about the managed devices by contacting each MND 104-105 separately and retrieving the necessary information using a plurality of SNMP Get and GetNext operations, for example. The information requested generally relates to the status, configuration, and performance of managed network devices and is described in the form of a managed information base (MIB). The one or more values returned from the MND 104-105 are often stored in the local database 110 where it is available when needed by network management applications that manage assets or track medium access control (MAC) addresses in the network, for example.
In order for the information stored in the local database 110 to be useful in managing the network 106, it must be readily available, accurate, and updated in a timely fashion so that the information remains current. In this regard, the CNMS 102 regularly polls the MNDs 104-105, retrieves the necessary information, and updates the data or database 110 for the CNMS applications. In response to polling, the CNMS 102 generally receives all information from a MND, not just the information that has changed since the last time information was received.
Under limited circumstances, the CNMS 102 will also receive SNMP traps, i.e. notifications, from a MND when the network 106 or a MND experiences certain problems or a specified event has occurred. If network system resources are unavailable or a network link is down, for example, an SNMP Trap is transmitted from the network device to the CNMS 102. In response to a SNMP TRAP message, the CNMS 102 generates a request for the appropriate information to assess the problem, waits to receive a response from the MND, and then updates its database.
The accuracy of the database 110 is therefore dependent upon the frequency at which the CNMS 102 polls the MNDs 104-105, and on the speed with which the NMS can process SNMP Traps. Unfortunately, the ability of the CNMS 102 to maintain an accurate database 110 is hampered by the heavy workload placed on the CNMS 102 by the need to poll and respond to Traps. In an enterprise network that has hundreds of MNDs, for example, this workload could overwhelm the CNMS 102 and substantially impair its availability. Frequent polling also places a burden on the network device to process the information requests and respond with the requested information.
The inaccuracy of the information retained at the CNMS 102 may also be exasperated by the inherent unreliability of SNMP or other management protocols that rely on user datagram protocol (UDP). Since packets transmitted using UDP are not guaranteed, a CNMS 102 may be required to poll a MND multiple times before receiving the accurate information.
Accordingly, in order to maintain readily available, accurate and updated network resource information, there is a need for new type of a resource manager.